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e-Motions is an Eclipse-based visual timed model transformation framework with a Real-Time Maude 
semantics that supports the usual Maude formal analysis methods, including simulation, reachability 
analysis, and LTL model checking. e-Motions is characterized by a novel and powerful set of con- 
structs for expressing timed behaviors. In this paper we illustrate the use of these constructs — and 
thereby implicitly investigate their suitability to define real-time systems in an intuitive way — to 
define and formally analyze two prototypical and very different real-time systems: (i) a simple round 
trip time protocol for computing the time it takes a message to travel from one node to another, and 
back; and (ii) the EDF scheduling algorithm. 



1 Introduction 



Model-driven engineering (MDE) is becoming a widely accepted approach for developing complex dis- 
tributed applications. MDE advocates the use of models as the key artifacts in all phases of system 
development, from system specification and analysis to implementation. For this purpose, it makes use 
mainly of two technologies: Domain-specific modeling languages (DSMLs) and model transformations. 

DSMLs are used to represent the various facets of a system in terms of models. Such languages sup- 
port higher-level abstractions than general-purpose modeling languages, and are closer to the problem 
domain than to the implementation domain. The abstract syntax of a DSML defines its domain concepts 
and their structural relationships. In MDE, the abstract syntax of a DSML is usually defined by a meta- 
model, which can be seen as a UML class diagram that describes the concepts of the language and the 
structuring rules that constrain the model elements and their combinations. The concrete syntax of such 
a DSML defines the actual notation used to represent the domain concepts, and is typically given as a 
mapping from the metamodel elements to a textual or (for visual languages) graphical notation. 

In MDE, the behaviors of a DSML can be defined as in-place model transformations, which define 
the possible dynamic evolutions of valid models in the language. There are several in-place model 
transformations approaches for specifying the behavior of a DSML (see [11] for a brief survey). 

Real-time embedded systems, such as, e.g., embedded medical devices and automotive and avionics 
systems, are both hard to design correctly, since subtle timing issues impact system correctness, yet are 
safety-critical systems, whose failures could result in significant losses to human lives and/or valuable 
assets. Therefore, the applications of MDE to such real-time systems should be supported by automated 
formal analyses. To the best of our knowledge, there are two model transformation frameworks for 
real-time systems within the EcUpse framework that support both reachability analysis and LTL model 
checking. They both have a Real-Time Maude [T| semantics and can be formally analyzed in Maude |3l- 

One such framework is the timed extension of the M0MENT2 model transformation framework 
defined by Boronat and Olveczky in |1|. To support the definition of timed behaviors, this approach 
provides a set of "timed constructs," namely, timers and clocks with different growth rates. These con- 
structs are special Ecore classes with a predefined Real-Time Maude semantics in M0MENT2. To define 
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timed behaviors, timer and/or clock objects must be added to the models. In M0MENT2, adding timed 
behaviors can be done in a non-intrusive way (i.e., without modifying the original metamodel) using 
M0MENT2's support for multi-model transformations UJ. 

The other Eclipse-based framework for real-time systems with Maude formal analysis support is 
the e-Motions model transformation framework ||9l[T0]|. One key difference between M0MENT2 and 
e-Motions is that the latter puts even more emphasis on making models as high-level and intuitive as pos- 
sible. In contrast to M0MENT2's textual model transformation rules, e-Motions is designed to support 
the definition of visual DSMLs by specifying also a concrete syntax for the elements in the metamodel, 
and by allowing the elements in the metamodel to map to graphical objects. 

The approach to support timed behaviors in e-Motions is completely different from the one in MO- 
MENT2. Since the focus of e-Motions is on providing a high-level intuitive formalism, e-Motions pro- 
vides support for using timed behaviors using different kinds of timed model transformation rules. 

M0MENT2 provides a built-in metamodel of basic timing constructs, thus allowing the possibility 
of associating appropriate clocks and timers to the elements of user models, which are then manipulated 
by multimodel transformations. To free the user from the burden of dealing with timing constructs, e- 
Motions provides a high-level way of defining timed behaviors by providing different kinds of timed 
model transformation rules. For example, model transformation rules can have a duration, which can 
be strict or given by a time interval. Rules can be either atomic, to represent actions that have no effect 
until it has been completed, or on-going, to represent continuous actions. Rules can be declared periodic, 
eager or non-eager, etc. The different rules and their use is explained in more detail in Section [2] 

Since e-Motions proposes such novel and powerful rules for defining timed behaviors within a formal 
model transformation framework, there are two critical and closely related issues that must be addressed: 

1. How can these new timed features be used to define "real" timed systems and languages? 

2. How convenient and intuitive is e-Motions in practice to define timed systems and languages in a 
visual style? 

Although e-Motions has already been used for developing several systems (see, e.g., fO", T^] and 
|http : //atenea .Ice .uma . es/E-motions), they were intended to illustrate the e-Motions ap- 



proach, and did not focus on timing aspects. This paper addresses the above issues by showing how 
e-Motions can be used to visually specify and formally analyze systems in two very different but proto- 
typical classes of real-time systems: distributed network protocols, and scheduling algorithms. 

Scheduling is a core issue in real-time systems, and plays a central role in modeling languages such 
as the AADL modeling standard for avionics and automotive embedded systems used in industry |[T3]| . 
Obviously, if e-Motions should be able to handle such embedded systems and AADL models, it must 
support the definition of scheduling in a simple and natural way. 

Since e-Motions is a new framework with novel timed features we want to illustrate, we focus on 
showing the entire specification of smaller systems, instead of showing small isolated fragments of large 
and complex systems. Therefore, in this paper, we apply e-Motions to the following systems: 

1. A simple protocol for measuring the round trip time between neighboring nodes in a network. 
Although this example is small, it contains many of the key features of distributed real-time proto- 
cols: local clocks and timers, nondeterministic message transmission times, periodicity of protocol 
runs, etc. An important reason for selecting this example is also that it was used to illustrate timed 
model transformations in M0MENT2; therefore, the reader can compare for herself the two very 
different styles of defining real-time systems in a formal model transformation framework. 

2. The well known earliest deadline first scheduling algorithm (see, e.g., ||2||). 
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The paper is organized as follows: Section [2] briefly recalls e-Motions; Section [3] shows how the 
round trip system has been specified and formally analyzed in e-Motions; and Section |4] does the same 
for the scheduling algorithm. Finally, Section[5]presents some concluding remarks. 

2 Modeling and Analyzing Time-Dependent Behavior with e-Motions 

e-Motions S is a DSML and a graphical tool developed for Eclipse that extends in-place model trans- 
formation with a model of time and mechanisms to state action properties, designed for the specification 
of real-time DSMLs' behavior. 

Once we have defined the structure of our language with a metamodel, we are ready to define its 
dynamic behavior with e-Motions. The e-Motions tool enables the use of a graphical concrete syntax of 
the language in the specification of its behavior through the definition of a graphical concrete syntax (gcs) 
model (see |8|). This model is automatically generated from the definition of our DSML's metamodel, 
and once it is created, we only have to assign a picture to each metaclass of our metamodel. 

One way of specifying the dynamic behavior of a DSML is by describing the evolution of the mod- 
eled artifacts. In MDE, this can be done using model transformations supporting in-place updates f?*!. 
The behavior of the DSML is then specified in terms of the permitted actions, which are in turn modeled 
by the model transformation rules. This approach provides a very intuitive way to specify behavioral 
semantics, close to the language of the domain expert and at the right level of abstraction |J5l. 

The behavior of a DSML is then specified by a set of graphical in-place rules, each of which repre- 
sents a possible action of the system. These rules are of the form / : [NAC]* x LHS — ;■ RHS, where I is the 
rule's label (its name), and LHS (left-hand side), RHS (right-hand side) and NAC (negative application 
conditions) are model patterns that represent certain (sub-)states of the system. The LHS and NAC pat- 
terns express the preconditions for the rule to be applied, whereas the RHS represents its postcondition, 
i.e., the effect of the corresponding action. Thus, a rule can be applied, i.e., triggered, if an occurrence 
(or match) of the LHS is found in the model and none of its NAC patterns occurs. Generally, if several 
matches are found, one of them is non-deterministically selected and applied, producing a new model 
where the match is substituted by the appropriate instantiation of its RHS pattern (the rule's realization). 
The model transformation proceeds by applying the rules in a non-deterministic order, until none is ap- 
plicable — this behavior can be modified by some execution control mechanism, e.g., strategies |[3l [T2l . 

Contrary to standard in-place transformation approaches, the e-Motions tool distinguishes two types 
of timed rules: atomic and ongoing rules. One natural way to model time-dependent behavior consists 
in decorating the rules with their durations, i.e., by assigning to each action the time it takes. Atomic 
rules are defined in such a way. As normal in-place transformation rules, an atomic rule can be triggered 
whenever a match of its LHS, and none of its NAC patterns, is found in the model. Then, the action 
specified by such rule is scheduled to be realized between t and t' time units later, where [t,t'] represent 
the duration of the rules specified as an interval of time. At that time, the rule is applied by substituting 
the match by its RHS and performing the attribute computations. Atomic rules also admit a parameter 
that specifies the period of an action. If a rule has this value set, the rule will be tried to be triggered at 
the beginning of each period, and if it cannot be so (i.e., if its precondition is not satisfied), it will not be 
enable until the next period. 

Note that in e-Motions actions may have now a duration, and therefore elements can be engaged in 
several actions at the same time. The triggering of an atomic rule is only forbidden if another occurrence 
of the same rule is already being executed with the same participants^ The only condition for the final 



We call participants of a rule to those elements that instantiate the rule's LHS pattern. 
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application of an atomic rule is that the elements involved are still there; otherwise the action will be 
aborted. If we want to make sure that something happens (or does not happen) during the execution 
of an action, we can make use of action execution elements to model the corresponding exceptional 
behavior (see 121 for further details). 

Ongoing rules allow the modeling of actions that are continuously progressing and require to be 
continuously updated. Think for instance of an action that models the behavior of local clocks, whose 
time increases continuously with time. These properties must be always updated, since other rules may 
depend on their value. Ongoing rules are used to model actions that do not have a priori duration time 
— they progress with time while the rule preconditions (LHS and NACs) hold, or until the time limit of 
the action (if set) is reached — and are required to be continuously updated — their effects are always 
computed before the triggering of any atomic rule. 

Once we have defined the behavioral specifications of our DSML using e-Motions, we can perform 
simulation, reachability analysis, and LTL model checking analysis of our DSML models. Currently, 
only simulation can be performed directly in the e-Motions tool. In order to perform reachability and 
model checking analysis we need to move to the Maude system [3| (which is also available for the 
Eclipse platform). In [lOJ, we show how Maude can be used to provide semantics to real-time DSMLs. 
The e-Motions tool automatically generates (by using model transformations) the Maude specifications 
of the metamodel of the DSML, its behavior, and an initial model. The result of the transformation is a 
rewriting logic specification of the system, which is executable and allows us to simulate and formally 
analyze it. 

In particular, the operator <<_; _>> is useful to define analysis commands without having to know 
the Maude representation of an e-Motions language. The term << ocl-expr ; model » evaluates the 
OCL expression ocl-expr in the model model. Therefore, to search for a model reachable from an initial 
model myModel that satisfies the OCL expression ocl-expr, we can use the Maude search command 

search [1] init (myModel) =>* { MODEL :@Model } in time TrTime 
such that « ocl-expr ; MODEL :@Model » . 

The generated models typically have an infinite number of reachable states; to ensure that search 
commands terminate, one can either restrict the search to a given depth (search [1,1000] ...). 
or, as proposed in HI, one can change the generated Maude specification by modifying the tick rule so 
that time does not advance beyond a desired time boundjj 

We can use the operator <<_; _>> to define atomic state propositions for linear temporal logic (LTL) 
model checking purposes. For example, to define a proposition p to hold in all models where the OCL 
expression ocl-expr holds, we can define 

op p : — > Prop [ctor] . 

ceq { MODEL :@Model } in time T : Time |= p = true if « ocl-expr ; MODEL : @Model » . 

An LTL formula is then constructed from such atomic propositions and the usual Boolean and LTL 
connectives, such as ~ (negation), \/ (disjunction), /\ (conjunction), -> (implication), [ ] (always), <> 
(eventually), U (until), and so on. One can then model check whether the LTL formula formula holds 
in myModel by giving the Maude command 

red modelCheck( init (myModel ) , formula) . 



^This is slightly less convenient than in MOMENT2, where we can achieve the effect of time-bounded analysis by just 
adding a new timer to the initial model. 
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3 Specification and Analysis of a Round Trip Time Protocol 

Estimating the round trip time between two nodes in a network — i.e., the time it takes for a message 
to travel from source to destination, and back — plays an important role in many large communication 
protocols. In this section we present a visual modeling language that can be used to specify a simple 



round trip time estimation protocol. Section 3.1 gives a brief overview of the protocol. Section 3.2 



presents the modeling language specifying the protocol, and Section 3.3 shows how the system can be 
formally simulated and analyzed. 



3.1 The Round Trip Time Protocol 

The round trip time protocol used in this paper is a fairly simple protocol that aims to estimate the 
current round trip time between neighboring nodes in a network as follows: Each node starts a round of 
the protocol by sending a request message to its (only) neighboijjwith a time stamp that records the local 
time at which the request was sent. When a node receives a request message, it immediately responds 
by sending a response message with the original time stamp back to the sender. When a node receives 
the response message containing its original time stamp, it can easily compute the round trip time using 
its local clock. Since the network load may change, and since messages may get lost, each node starts a 
new round of the protocol every 100 time units to get up-to-date round trip time estimates. We assume 
that the message transmission time is between 5 and 20 time units, and that messages may be lost. 

3.2 The e-Motions Specification of the Protocol 

This section presents a DSML that defines the round trip time protocol in e-Motions. 

The class diagram in Figure [T] shows the metamodel that defines the abstract syntax of the DSML 
defining the protocol. A Node object represents a node in the network, and is identified by its id attribute. 
The neighbor attribute denotes the identifier of its only neighboi|jand the rtt attribute denotes the desired 
current round trip time estimate. The local time of a node is given by the time attribute of the node's 
associated local clock. We have two kinds of messages, RequestMessage and ResponseMessage, that 
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Figure 1 : Abstract syntax of the round trip protocol language. 



are subclasses of the generic Message class. A message contains a requestTime attribute denoting the 



Note that the neighbor relation does not have to be symmetric. 

There are obviously many other ways to model such a system, including letting neighbor refer to a concrete object instead. 
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time stamp, and to and from attributes denoting, respectively, the receiver and sender of the message. 
When a message is created, it is "sealed," and the message can only be read when the seal has been 
removed; this models message delays as explained below. 

The concrete syntax for the round trip time protocol language that assigns a graphical object to each 
class in the abstract syntax is given in Figure [2] 



tirttp 







h V 




?> 




Clock 



Me;;age 



RequestMessage 



ResponseMessage 



Node 



Figure 2: A concrete syntax for the round trip time protocol language. 

The real-time behavior of the DSML can now specified by a set of visual model transformation rules. 

Figure [3] shows the Request rule, which starts a round of the protocol for a node n. It models how 
the node n creates a request message m to its neighbor. The message is initially sealed, and includes the 
time of its creation (given by the node's local clock). We consider that the action is instantaneous, and 
therefore the rule's duration is set to the interval [0,0]. This is periodic rule, with period 100 (notice 



ES Request 

T in \m <P lOO 



1 LHS 



1 : Node 








iJ RHS 



n : Mode 



c ; Clock 




m : Mes£aqe 



requestTime = ctima 
from = n.id 
to = n.reiqhboi 
sealed = true 



Figure 3: The Request periodic rule. 



the loop icon in the header of the rule). Remember that, unless the rule is soft, an execution of a rule is 
scheduled as soon as possible for each set of objects that matches a rule's left-hand side. Therefore, the 
above rule will be applied every 100 time units /or each Node. 

Successful message transmission is modeled by the Transfer rule shown in Figure |4] This action 
takes between five and twenty time units, and removes the seal of a message, which indicates that the 
message can be received. Any kind of message may get lost at any time, what is modeled by the Lost 
rule in Figure [5] 
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B Transfer 
©Tin [5,20] 



B LHS 




sealed = true 



ii RHS 




sealed = false 



Figure 4: The Transfer atomic rule. 



H Lost 
® T in [0 01 



1 LHS 



m ; Messdqe 



d 



li] RHS. 



Figure 5: The Lost atomic rule. 



Figure [6| shows the instantaneous atomic rule that appUes when the seal of a request messagqjml 
has been removed; that is, the message is ready to be received. The intended recipient n then consumes 
the message and sends a new (sealed) response message to the sender of the request message. This new 
message also includes the same time stamp that was received in the request message. 

When the response message is received, the instantaneous rule ComputeRtt in Figure|7]computes the 
receiver's rtt value by subtracting the time stamp m.requestTime from the current value of its local clock. 

Finally, the ongoing (notice the purple arrow) rule LocalTime Elapse, shown in Figure [8} increases 
the time value of each clock in the system by the elapsed time T. 

3.3 Formal Analysis of the Protocol 

Let the model shown in Figure |9] be the initial model of the system. This model is composed of two 
nodes and their local clocks. 

Since a message transmission can take anywhere between five and twenty time units, we could expect 
that the round trip times will range between ten and forty time units. This property can easily be checked 
using the Maude's search command. This command allows us to explore (following a breadth-first 



^Remember that messages with a (left to right) blue arrow are request messages, and messages with a (right to left) green 
arrow are response messages. 
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E LHS 



ml 




to = n.id 
lealed = false 



©Tin [0,0] 




lij RHS 


m2 


n 

ff 


from = n.id 

to = ml.from 

requestTime = ml,reque;tTime 

sealed = true 



Figure 6: The Response instantaneous rule. 
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© 






Figure 7: The ComputeRtt instantaneous rule. 



strategy) the reachable state space in different ways. Thus, we move to the Maude environment, and 
check if a model with a node whose rtt attribute is set to a value lower than ten time units or greater than 
forty time units can be reached: 

search [1] init (rttpModel) =>* { MODEL :@Model } in time T : Time 
such that « Node@rttp . alllnstances 

-> exists ( n I (n . rtt@OCLSf > 40) or (n . rttgOCLSf < 10)) ; 
MODEL :@Model » . 



No solution. 
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Figure 8: The LocalTime Elapse ongoing rule. 



J^ff SB 



id = 'nodel' 
neighbor = 'node2' 



id = 'node2' 
neighbor = 'nodel' 





time = 



time = 



Figure 9: The rttpModel initial model. 



With this command, we are looking for a model MODEL that satisfies the condition expressed as an 
OCL expression in the such that clause as explained in Section|2] In this case, the search command does 
not find any solution, and therefore we can conclude that starting from our initial model, the round-trip 
time value of every node will always range between ten and forty time units. 

We can also check whether the local clocks of the system are always synchronized by searching for 
a state that does not satisfy it, i.e., by looking for a state on which two clocks have different time values: 



search [1] init (rttpModel) =>* { MODEL 


@Model } 


in time T:Time 


such that « 'clockl . time@OCLSf O 


'clock2 


timeSOCLSf ; MODEL :@Model » . 


No solution. 
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4 Earliest Deadline First Scheduling 

This section explains how we can visually specify and formally analyze the well known earliest deadline 
first (EDF) scheduling algorithm in e-Motions. Even though model checking is not necessary to decide 
schedulability of this simple protocol, for much more complex scheduling algorithms where schedula- 
bility is very hard to analyze analytically, Real-Time Maude model checking analyses can indeed be 
successfully apphed to analyze schedulability IS. 

4.1 The EDF Scheduling Algorithm 

In EDF scheduling with periodic tasks (see, e.g., 13), we are given one or more processors and a set 
of tasks Ti , . . . , T„, where each task t, is served by a constant bandwidth server Si with period pi and 
execution time e,-. The server Si executes the instances of T,- in rounds of length pi, and in each round it 
must have access to a/the processor for time e, in total. 

Tasks can be preempted (i.e., suspended in the middle of an execution to allow the processor to 
execute tasks with higher priority), and it is always the task(s) with the earliest deadline that have the 
highest priority. That is, it is always the server with the least amount of time remaining of its current 
round that should be executing (unless it has ended its execution in the round). 

Therefore, in EDF, the behavior of a server 5, can be summarized as follows: 

• At the beginning of each round: if a processor is idle, the server starts executing on the processor; 
if a processor is not idle, but the time until the end of the executing server S'/s current round is 
greater than the period p,, then 5/ preempts (and suspends) Sj and starts executing; otherwise, the 
server Si starts waiting for an available processor. 

• A waiting or suspended server may start executing when another server stops executing, and there 
are no other waiting/suspended servers with higher priority. 

• When the server 5, has executed for a total amount of time e, in its current round, it releases the 
processor, to the waiting/suspended server (if any) with the highest priority. 

• When a server's round ends, it immediately starts a new round. 



4.2 Specifying EDF in e-Motions 

The class diagram defining the abstract syntax of the DSML specifying the EDF algorithm is given in 



Figure 10 In this metamodel, a system is composed of a set of servers and a set of processors. A 





0..1 currentSen/er 


@ Sen/er 




? period ; EInt 
? execTime ; EInt 
? deadline : EInt 
? remExecTime ; EInt 


@ Processor 















Figure 10: The EDF metamodel. 



processor can execute at most a server at a time (see the currentServer reference). Task servers are 
identified by their period (attribute period) and their execution time (attribute execTime). The deadline 
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and remExecTime attributes denote, respectively, the time until the end of the current round and the 
remaining execution time in the current round. The visual concrete syntax we have defined for the EDF 



example is shown in Figure 1 1 




Figure 1 1 : A concrete syntax for the EDF language. 



The model transformation rules in Figures T2p6 define the dynamic behavior of EDF. 

When the current round is over (i.e, the time remaining until the deadline is 0), the server s starts a 
new round by first setting its deadline attribute to the length of its period, and by setting the value of its 
remExecTime attribute, that denotes the remaining execution time of the new round, to whatever what 
left of the execution time in the previous round plus the execution time needed in this roundj^ This is 
modeled by the instantaneous atomic model transformation rule NewPeriod in Figure [12) As already 



B NewPeiioc 
T In [0,o; 



JLHS 



s ; Server 




deadline = 
remb<ecTTme = 



rr 




ceadflinie = s.pericd 
remtxecTime = texecTime 



Figure 12: The NewPeriod instantaneous rule. 



mentioned, unless an atomic rule is declared to be soft, it is applied as soon as it becomes enabled. 



In the instantaneous atomic rule ServerSelection, shown in Figure 13 the server s gets to execute if 



there is no other server with remaining execution in the period with earlier deadline, and the currently 
executing server (if any) has a strictly later deadline than s. 

The rule ServerSelection also applies when a server s2 finishes its execution in a round, if there is a 
waiting/suspended server. The case when a server s finishes its execution (i.e., s. remExecTime is 0), but 



there is no server waiting, is modeled by the instantaneous atomic rule ReleaseProcessor in Figure 14 
where s just releases the server at the end of its current execution if no server is waiting. 



If the system is schedulable, then S. remExecTime is always at the end of each period. 
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Figure 13: The ServerSelection instantaneous rule. 
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si ; Server 






remExecTime = 



Figure 14: The ReleaseProcessor instantaneous rule. 



Finally, we have two ongoing rules: Rule Execution in Figure 15 decreases the remaining deadline 
of each server according to the elapsed time T, until the node reaches the end of its round, and the 



rule DecreaseDeadline in Figure 16 decreases the remaining execution time of each executing server 
according to the elapsed time. 
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B LHS 



B Execution 

©T ^ s.remExecTime 




U RHS 







remExecTime = s.remEHecTime - T 



Figure 15: The Execution ongoing rule. 



J LHS 



B Deci easeDeadline 
©T < 3. deadline 




iJRHS 




deadline = s. deadline - T 



Figure 16: The DecreaseDeadline ongoing rule. 



4.3 Analyzing the EDF Algorithm 

We can use the generated Maude specification of the EDF language to analyze whether a given set of 
servers is schedulable; that is, whether all servers can execute for the allocated execution time execTime 
in each round. 







execTime = 1 
period = 8 



execTime = 2 execTime = 4 

period = 5 period = 10 



Figure 17: The edfModel initial model. 



Figure 17 shows an initial model edfModel with three servers and one processors. To analyze 



62 Formal Visual Modeling of Real-Time Systems in e-Motions: Two Case Studies 



whether this server set is schedulable, we search for a reachable model which can not execute for the 
desired amount of time in some round; that is, a model in which the remaining execution time is greater 
than the deadline for some server s : 

search [1] init(edf Model) =>* { MODEL :@Model } in time T:Time 
such that « Server@edf . alllnstances 

-> exists ( s I s . deadline@OCLSf < s . remExecTime@OCLSf ) ; MODEL :@Model » . 



5 Concluding Remarks 

We have shown how two fairly small, but "non-artificial," real-time systems in very different domains 
can be specified in the visual model transformation framework e-Motions. We have also shown how 
the Maude tool can be used to formally analyze the automatically synthesized Maude models. We leave 
it up to the reader to evaluate the convenience of using e-Motions for the specification and analysis of 
real-time systems, and also encourage her to compare this work with the specification and analysis of the 
same round trip example in the timed model transformation framework M0MENT2 lU. 

Our personal impression is that it seems quite convenient to model systems in this way; however, the 
analysis support could be better integrated within e-Motions, despite the very significant advantage of 
having the <<_; _>> operator, which allows us to easily define any reachability and LTL model checking 
query without knowing anything about the internal Maude representation of our system. 
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